Table of Contents

Module: Generators .\src\TW\UML\Generators.py

Generating things from UML Models... Design Notes Only; Not Yet Implemented

Design Overview

Generation is done by an aspect added into a generic UMLModel component. Each UML Element class (Classifier, AssociationEnd, Attribute, etc.) has a generate() method which will return a Template for the respective element of the UML model. In general, UML elements derived from Namespace will call the generate() methods of their ownedElements and install the results in their own output template, but precisely which ownedElements they use, may vary from element type to element type.

The framework tries to keep semantic interpretation to a minimum, focusing instead on mapping metadata into a component specification. For example, rather than try to interpret TaggedValues or convert them into attributes, they are simply placed into a data structure that a Builder can later interpret. This means that horizontal frameworks can easily incorporate their own specialized uses of TaggedValues without requiring any extensions/alterations to the basic generator framework.

For now, the generation aspect's focus is on packages, classes, attributes, associations, tagged values, and stereotypes. Support for other types of objects may come later. To support these basic types, only a few semantic interpretations are necessary:

  • Base classes - generalization relationships must be interpreted to specify a template's base classes

    • Note: naming rules must be established so that the generating class knows to refer to bases by fully qualified names, partial names, etc. Most likely this could be implemented through a "generation context" object passed around among generate() methods, perhaps with a getGlobalNameForClass() method to implement the naming policy.

    • Does UML actually have any way to determine ordering of base classes??? Eeek...

  • Service-Element-Feature options, controlled by TaggedValues

    • Whether a class specifies Service, Element, or both

      • How do we reference Element from Service and vice versa?

      • Will we have problems with having two outputs for one input? Note that associations & attributes need to reference a service rather than an element, so they need to know a thing's service name. Ugh. Perhaps a TWServiceName ComputedFeature is the answer. Name munging will also need to occur.

    • Any name mapping for the Service (e.g. "Vertex"->"Vertices")

    • It may be that we can also have the policy object control things like default bases in the absence of explicit bases..

  • TaggedValues and StereoTypes

    • Create a _umlTaggedValues mapping attribute from explicitly tagged values

    • How to handle inherited and stereotype-granted tagged values?

      • Seperate _umlStereotype object w/extra attributes for stereotype info?

      • Make TaggedValues mapping entries contain sequences of explicit and implied values for each tag?

  • Interfaces

    • Should we create scarecrow interfaces?

    • Should realizations create __implements__ relationships?

    • Should realizations imply anything else? (E.g. being an Element or Service)

  • Misc.

    • Put comments in as docstrings?

    • Other metadata:

      • subclasses (svc & element both)

      • UML flags: abstract, root, leaf, persistent...?

      • lists of contained features & services (Is sequence important? If not, could be done more flexibility w/postprocessor builder object in the frameworks that need them. Of course, having a standard might be nice too...)

    • Associations - need to work out the endedness issues a bit... multiplicity mapping to SEF types... etc.

Policy Object

Things to be handled by the policy object:
  • Creation of a template object for a given generate() (based on source object, TaggedValues, base class names, and default "flavor")

    • Default implementation should make a Template() object with bases as the munged base class names, and __name__ as the local UML element name.

  • Naming of references to other elements

    • Default implementations will probably be either a mapping of namespace prefixes to new prefixes, or a "flat" namespace (w/optional name prefix, and a mungeName() method overrideable in subclasses).


Table of Contents

This document was automatically generated on Tue Mar 05 10:33:45 2002 by HappyDoc version WORKING